There are well known specifications which define relationships between a proving party (typically a user), an identity provider (aka IdP), and a service provider (aka SP) wherein the proving party requests to access to a restricted service from the service provider. The service provider requests and obtains an identity assertion from a security token of the proving party. The identity assertion is derived from the information stored in the security token according to a policy access of the desired service provided by the service provider. The identity assertion comprises statements of the proving party which allowing to prove that the proving party fulfills the requirements of the policy access for the desired service—such as a user name, the birth date, the user address. . . .
On the basis of this assertion, the service provider can make an access control decision—in other words it can decide whether to authorize access to the service for the connected proving party.
One major problem is to ensure that the statements of the identity assertion comprise only information needed to access to the requested service. User consent is of uttermost importance to ensure that only statements necessary to access to the service are disclosed to the service provider, this is to prevent user profiling and/or traceability.
But in order to achieve such selective disclosure it is known cryptographic solutions such as U-Prove. U-Prove is a Blind signature cryptography technology. Another known cryptographic solution is identity mixer with group signature cryptography.
The protection mechanism utilized by these solutions relies on a Graphical User Interface (GUI) of a terminal through which the proving party interacts with the service provider. This GUI makes the protected data vulnerable to attack by a thief having sufficient hardware/software know-how, diagnostic equipment, and hacking abilities. Indeed, the GUI as intermediary for communication with the user does not prevent misleading or deceiving the user because obviously any GUI may be subject to attacks bearing on browser's or embedded script security beaches.
Furthermore, nowadays, the user has few or no means to check whether the requirements of the policy access are tampered with before to be delivered on his security token. Even if a secure messaging is established between the security token and the service provider, the content of the policy access are fundamentally still exposed to the risk of being modified by the service provider who sends it to the user. Secure messaging ensures integrity and confidentiality of the payload but does not prevent from changing the payload before encrypting it and delivering it to user's security token. Therefore, the user has no means to check whether the content of the identity assertion transmitted to the service provider corresponds exactly to the user data needed to access to the service.
There is thus a general need in the art for a method overcoming at least the aforementioned shortcomings. A particular need exists in the art to make sure that the user can check the statements of the identity assertion before delivering his consent to its transmission to the service provider.